Various forms of network storage systems are known today. These forms include network attached storage (NAS), storage area networks (SANs), and others. Network storage systems are commonly used for a variety of purposes, such as providing multiple users with access to shared data, backing up critical data (e.g., by data mirroring), etc.
A network storage system includes at least one storage server, which is a processing system configured to store and retrieve data on behalf of one or more client processing systems (“clients”). In the context of NAS, a storage server may be a file server, which is sometimes called a “filer”. A filer operates on behalf of one or more clients to store and manage shared files in a set of mass storage devices, such as magnetic or optical disks or tapes. The mass storage devices may be organized into one or more volumes of a Redundant Array of Inexpensive Disks (RAID). Enterprise-level filers are made by Network Appliance, Inc. of Sunnyvale, Calif. (NetApp®).
In a SAN context, the storage server provides clients with block-level access to stored data, rather than file-level access. Some storage servers are capable of providing clients with both file-level access and block-level access, such as certain Filers made by NetApp.
Filers made by NetApp have the ability to generate a Snapshot™ of stored data. A Snapshot is a persistent, read-only, point-in-time image of data set, such as a volume, file, or logical unit number (LUN). A Snapshot captures the exact state of data in a data set at the point in time that the Snapshot was taken. This allows the state of the data set to be restored from the Snapshot in the event of, for example, a catastrophic failure of the storage system or corruption of data. The ability to restore data from a Snapshot provides administrators with a simple mechanism to revert the state of their data to a known previous state in time as captured by the Snapshot. Creation of a Snapshot or restoring from a Snapshot can be controlled from a client-side software tool, such as SnapDrive™ or SnapManager® for Microsoft® Exchange, both made by NetApp.
Desirable features to have, when restoring data from a Snapshot, include speed, space efficiency, and the ability to restore data at a fine level of granularity. An existing technique for restoring from a Snapshot is known as volume SnapRestore® from NetApp. Volume SnapRestore allows an entire volume to be restored from a Snapshot relatively quickly and in a predictable amount of time. However, often a user would like to restore less than an entire volume from a Snapshot, such as a single file or LUN, which cannot be done with volume SnapRestore.
Another existing restore technique from NetApp, known as single-file SnapRestore (SFSR), allows a single file or LUN to be restored from Snapshot. However, SFSR takes a non-deterministic amount of time to complete, depending on the size and layout of the file or LUN. This uncertainty can cause users anxiety or irritation. This issue is exacerbated by the fact that, with either volume SnapRestore or SFSR, a storage client cannot perform any input/output (I/O) operations (i.e., reads or writes) on the data set that is being restored until the restore process is complete. Depending on the size and layout of the data set, the result may be anywhere from a few minutes to an hour or more during which data cannot be served to the client. This amount downtime may be unacceptable for applications that are sensitive to downtime and need to be quiesced during backup and restore operations, such as databases and file systems.
Storage space consumption is also an issue when restoring from a Snapshot. Existing restore techniques require at least as much free storage space to be available for the restore as consumed by the Snapshot. For example, if a Snapshot is 100 GB, known restore techniques could result in an additional 100 GB being consumed in the active file system. In a system where storage space is at a premium, this amount of storage space consumption may be undesirable.